-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat!: new abigen!
, setup_contract_test!
, and handling of shared types
#763
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Awesome work! 🎉 I really like it!
Co-authored-by: Halil Beglerović <git@hal3e.io>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
AWESOME WORK. I left a lot of comments because you know I love to nitpick, but I'm super impressed by how clean this all is, and I don't think they are actually "requested changes". So I'm putting it on "approve" because we all want this to be merged fast haha.
packages/fuels/tests/bindings/sharing_types/contract_b/src/main.sw
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. Congrats again on the amazing work you did!
Co-authored-by: iqdecay <victor@berasconsulting.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Phew... what a journey. Excellent work; I love the refactoring you did along the way.
I did the best I could, but I'm sure I could miss something; that's why long PRs are discouraged.
This is amazing, let's not do it again 😂
@segfault-magnet @iqdecay I've resolved some of the unresolved comments because they were all nits/discussions (plus, it was under approval anyway). I did this so we could merge this in a timely fashion. Feel free to continue these discussions in separate issues and tackle those in separate PRs if applicable! |
@segfault-magnet apart from the subject of the |
Yep, we could do the getters, will write a task along with the |
Created the getters issue (and will PR it soon), I'll let you create the discussion and tag me 😸 |
closes: #689
closes: #686
big thanks to @hal3e for his contributions. Love pairing up with the guy :)
As discussed, the only practical way of solving the issue of reusing types between contracts, scripts and predicates, is to generate the bindings at the same time.
Breaking changes (@digorithm )
abigen!
format changedsetup_contract_test!
format changedfuels_contract
.abigen_bindings
Abigen
changed its interface.abigen_bindings::some_contract_a_mod::SomeNonUniqueType
)Changes to
abigen!
To support the above,
abigen!
will now be called as follows:The parsing logic was enhanced to provide compiler hints to the user in case they get it wrong. These hints are tested via trybuild.
Examples:
Invalid program type used:
Invalid attributes:
others include:
If there are identical types, both in name and in their innards, they will be extracted to a separate module called
shared_types
. It looks something like this:Handling shared types
If any type or function inside
contract_a_mod
,contract_b_mod
... uses a shared type, it will reference it viasuper::shared_types::SomeSharedType
. It has to use relative references, likesuper
since the macro doesn't know in whichmod
it is being expanded into.In addition, due to the symbol collisions in #686,
use
statements are not injected into the generated code. Everything is referred to by its full path. aVec
is::std::vec::Vec
, String is::std::string::String
, etc.The std prelude is disabled for the generated code and a smaller, custom one, is used in its place with mostly traits inside, which can't collide with bindings ATM.
Also since we now have the possibility of symbol collision, we cannot do
pub use contract_x_mod::*
like we did before.Instead, Abigen will figure out a set of uniquely named symbols and only generate
pub use
statements for that set. Types that didn't getpub use
statements will need to be referred to by their exact path by the user.There is one caveat to this:
Suppose we have
ContractA
with typeSomeType
andContractB
with typeSomeType
. Also, suppose the twoSomeType
s have different internals, so they are not deemed to be 'shared types'.Currently, we will not generate
pub use
statements due to the fact that we're going to cause a collision.In the previous versions, if you ran
abigen!
twice, once for each contract. You'd get the following:this would work even with the collision due to how
::*
works -- it will disregard thecontract_a_mod::SomeType
due to it being 'overriden' by the secondabigen!
.I'm not sure if this behavior is useful for anybody, it actually took me by surprise.
But it is worth a mention since calling
abigen!
twice is still a thing, but will now produce a compile error since you'd end up with:Which is a collision, it doesn't have the
::*
overriding properties. The twopub use
statements are generated because the two invocations ofabigen!
didn't know about each other.I don't see this as much of a problem since you can always wrap the
abigen!
s in a mod, or, do the better thing, generate everything inside oneabigen!
so it knows not to put thepub use
statement for the non-unique symbol at all.Parent wrapping module
The result of
abigen!
is now wrapped inside the modabigen_mod
to avoid an edgecase regarding tests and shared types.Refactoring
Abigen went under a bit of refactoring to make having multiple contracts, scripts and predicates easier.
Generating types, wrapping in mods and other common operations have been lifted to the Abigen, while contract, script, or predicate-specific code resides in their respective files.
You'll also come across other helpers like
GeneratedCode
for merging and keeping track of the generated types so that we can generateuse
statements later on.FunctionGenerator
tries to extract as much of the duplication in the variousexpand_fn
functions as it can.Also, the structure has been shifted around a bit in the code_gen, choices were guided by a dependency graph striving to minimize inter-file dependencies.
setup_contract_test
macro rehaulFollowing the example of
abigen!
@hal3e and I have implemented something similar forsetup_contract_test
:Here is an example of what the new usage looks like:
In short,
Wallet
creates wallets and launches a provider with them,Abigen
does the abigen andDeploy
does the deploying :DWe've put some effort into cool compile-time error messages, i.e. trying to Deploy a contract you don't have, and similar checks.